home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / digital / 940274.txt < prev    next >
Internet Message Format  |  1994-11-13  |  21KB

  1. Date: Wed, 17 Aug 94 04:30:24 PDT
  2. From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
  3. Errors-To: Ham-Digital-Errors@UCSD.Edu
  4. Reply-To: Ham-Digital@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: Ham-Digital Digest V94 #274
  7. To: Ham-Digital
  8.  
  9.  
  10. Ham-Digital Digest          Wed, 17 Aug 94       Volume 94 : Issue  274
  11.  
  12. Today's Topics:
  13.                  900MHz phone spread spectrum systems
  14.                      [Q] best software for KAM+ 
  15.                 AUTOEXEC.NOS for NOS with BAYCOM modem
  16.                  Does a FAQ exist for packet newbys?
  17.                           Gateway within CA?
  18.                         Jnos-Enet Solved TnX !
  19.                           JVFAX Interfaces?
  20.  
  21. Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
  22. Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
  23. Problems you can't solve otherwise to brian@ucsd.edu.
  24.  
  25. Archives of past issues of the Ham-Digital Digest are available 
  26. (by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".
  27.  
  28. We trust that readers are intelligent enough to realize that all text
  29. herein consists of personal comments and does not represent the official
  30. policies or positions of any party.  Your mileage may vary.  So there.
  31. ----------------------------------------------------------------------
  32.  
  33. Date: 16 Aug 1994 17:53:42 GMT
  34. From: ihnp4.ucsd.edu!news.cerf.net!mvb.saic.com!MathWorks.Com!yeshua.marcam.com!zip.eecs.umich.edu!newsxfer.itd.umich.edu!ncar!newshost.lanl.gov!beta.lanl.gov!wolf@network.ucsd.edu
  35. Subject: 900MHz phone spread spectrum systems
  36. To: ham-digital@ucsd.edu
  37.  
  38. here's the summary of relevant details that arose from my earlier post
  39. requesting details on the 900 MHz ss phones.  i was somewhat dismayed;
  40. very few seemed to have any hard facts on these systems.  i tried to
  41. sort out the conflicting info, so some of this may not yet be right.
  42. hopefully someone in the know will enlighten us.
  43.  
  44. i had asked:
  45.  
  46. " does anyone have any details on the ss systems used in, say, the escort
  47.   phones?  spreading sequence generator, moduation methods, synchronization
  48.   schemes, etc.?  one of the felows that i talked with at cincinnatti microwave
  49.   suggested that their phones choose a spreading sequence randomly whenever the
  50.   phone gets used.  is this true? "
  51.  
  52. it turns out that there are at least two digital schemes for 900 MHz phones.
  53. the second, not ss, is what the tropez phone uses.  first i'll point out what
  54. appear to be open questions, then i'll summarize the tropez and then move on
  55. to the ss phones.  finally, i'll note the cryptographic security and attack
  56. issues that were mentioned and end with some micellaneous items.
  57.  
  58. ------------------------------------------------------------------------------
  59.  
  60. Open Questions:
  61.  
  62. what is the spreading sequence mechanism?  details?
  63. how is the sprerading sequence and digitized audio used?
  64. audio sampling rate?
  65. spreading sequence rate?
  66.  
  67. for the tropez, there are similar questions, though the modulation is not ss.
  68.  
  69. chip-set details?
  70.  
  71. ------------------------------------------------------------------------------
  72.  
  73. Tropez
  74.  
  75. one poster suggested:
  76.  
  77. >>p.s. There are reports that the audio is transmitted in the clear on 450 
  78. >>MHz. Not sure of the signal level, tho.
  79. >>
  80. >
  81. >yes... I reported this late last week... and am still researching it. My
  82. >phone though, is the Tropez 900 DL which is not spread-spectrum but 
  83. >digitally modulated on single carriers within the 900 MHz band.  What I
  84. >have found is that there is some leakage of in-the-clear audio in the
  85. >430 MHz amateur band from the handset.  Others have found and reported
  86. >similar signals.  I am trying to get someone from VTech (the manufacturer
  87. >of the phone) to discuss this with me...  but they seem to be having trouble
  88. >returning my calls.
  89.  
  90. thus it appears that the tropez does not use ss, and that there is a low level
  91. 430MHz or thereabouts (what is the exact frequency?) analog leak from the phone.
  92.  
  93. the same poster gave some details on the tropez phone's digital system:
  94.  
  95. >I believe the modulation is PCM... and it is scrambled with a one of
  96. >64K possible patterns that is chosen each time the handset is removed
  97. >from the base...
  98.  
  99. what is the pattern generation mechanism?  how is it in some sense "randomized".
  100. one guess would be that there is a continuously generated pseudorandom sequence
  101. and that the time that you start to use the phone determines the phase of the
  102. sequence relative to the start time...  this would be a silly sort of rng tho.
  103. but it would _suffice_ since it is not too difficult to design a pseudorandom
  104. sequence generator with a short correlation length.
  105.  
  106. one would also like to know if the pseudorandom sequence bit time is long, or
  107. short wrt the analog digitization time.
  108.  
  109. also, what is the method for using the pseudorandom noise with the digitized
  110. audio?  i.e., are the two x-or'd or something more "interesting"?
  111.  
  112. finally, if there are indeed 64K possible patterns, what generates and
  113. determines these patterns?
  114.  
  115. another poster commented on the modulation scheme, gave a bit rate, but did
  116. not comment on the number of pseudorandom patterns or their method of
  117. generation:
  118.  
  119. >I'm fairly satisified with the 900 MHz Tropez I've got right now.
  120. >It goes almost a block radius around my house.  The Tropez is *not*
  121. >spread-spectrum.. Tropez uses a single channel 16 KHz PCM signal
  122. >that is about 100 KC wide.  Unless you are in a super saturated
  123. >location, I am not convinced that spread spectrum is significantly
  124. >superior to the channelized units.
  125.  
  126. later they wrote, but no mention of what use is made of the "key":
  127.  
  128. >The PCM chip in the Tropez is made by Motorola. ... The CPU looks to be
  129. >something like a 6809 derivation.
  130. >
  131. >The key is a 16 bit word.  I don't know if there is an easy way to
  132. >get in sync once the initial hand-shaking is done -- probably there
  133. >is, because the system has to be farily robust in the presence of
  134. >signal interruptions and multipath distortion.
  135. >
  136. >I believe the code is not sent out over the air, but is downloaded
  137. >directly into the handset when you put the phone on the base unit.
  138.  
  139. then some comments on how the handset and base sync:
  140.  
  141. >I've noticed the base sends out a little ping when you set the the
  142. >handset on the base.  I surmised the ping does two things:  1.
  143. >Sees if anybody else is on the same channel, if so change to
  144. >another channel.
  145.  
  146.  
  147. ------------------------------------------------------------------------------
  148.  
  149. SS 900 MHz Systems
  150.  
  151. the folklore is that the 900 ss systems in use use direct sequence ss:
  152.  
  153. >My understanding is that these phones use direct sequence spread spectrum.
  154.  
  155. as to the synchonization scheme, the typical autocorrelation method was guessed:
  156.  
  157. >I think you sort of slide your sequence back and forth over the signal, and
  158. >when they're synced, the signal gets clear in an easily detectable way.
  159.  
  160. and another poster said:
  161.  
  162. >Once you know the code and have the incoming signal, you can use some
  163. >kind of sliding correlator- try the, say 63, possible starting points
  164. >for the sequence, and find which one produces the larges received
  165. >signal, ie the biggest correlation peak.  Then you continue to lock
  166.  
  167. and a comment on "64K" codes, which i don't understand at all!  whatever!
  168. maybe someone has some actual details on the ss systems in use?
  169.  
  170. >When they say "Uses digital spread-spectrum techniques with 
  171. >64,000 different codes," they may probably be saying that there's one 
  172. >sequence and 64K access codes to dial out, which is the same as an analog 
  173. >cordless with 64K security.
  174.  
  175. another comment on the spreading sequence (?) states:
  176.  
  177. >The best US system I have heard of uses 16 bit encryption...
  178.  
  179. clearly some details are missing!
  180.  
  181. my guess is that there is a lfsr that is 16 bit wide, generating a 64K
  182. m-sequence that is x'or'd with the digitized analog...  the normal trick.
  183.  
  184. again, what is the bit rate of the prng?  how many spreading sequences are
  185. available? etc. so far we've seen no good details...
  186.  
  187. a comment on the setting of the "security code", no details on what "security
  188. code means":
  189.  
  190. >According to the AT&T owners manual,  The security code changes
  191. >automaticly when the phone goes off hook.
  192.  
  193. one poster gave some information on the number of legally available spread-
  194. ing sequences:
  195.  
  196. >Each Spread Spectrum user in the 900MHz range has a choice of 4
  197. >types of spreading.  I believe they are the same type as the ones allowed 
  198. >for Hams.
  199.  
  200. note: 2 lfsr schemes x 2 prng schemes = 4 types of modulation schemes.  these
  201. are the legally available ham modes.
  202.  
  203. ------------------------------------------------------------------------------
  204.  
  205. Crypto and Security
  206.  
  207.  
  208. one poster writes:
  209.  
  210. >Direct sequences are easy to figure out. (These are single shift register
  211. >generators.) If you know how long it is, say N stages, all you need is N+1
  212. >bits to figure out the code and the synch.
  213.  
  214. another responds:
  215.  
  216. >Strictly speaking what you say is true (and you need 2N consecutive
  217. >bits) with two (important) conditions:
  218. >
  219. >        1. The shift register must be _linear_, i.e., the feedback
  220. >        bit must be an XOR of some fixed subset of the current bits
  221. >        of the shift register.
  222. >
  223. >        2. It is good to have access to the pure spreading sequence 
  224. >        _unmodulated by data_, you see, sometimes one period
  225. >        of the spreading sequence spans more than one data bit
  226. >        and this causes inversions.
  227. >
  228. >Of course, these two problems are trivial in a crypto sense. If it
  229. >is right that they're using m-sequences (maximal length sequences)
  230. >in these cordless phones, yes m-sequences are linear hence
  231. >satisfy condition 1.
  232.  
  233. the second poster gets close to the issue of how to attack a ss phone
  234. system.  note that if the quiet time digitized audio spans more than
  235. 2N bits that you then have an instant "in".
  236.  
  237. is there a reference to the result mentioned?
  238.  
  239. we need details on the sppreading sequences, rates, etc.  anyone have a phone
  240. and care to look up their part numbers?
  241.  
  242. another comment on security.  it would appear that security is nonexistent if
  243. only a few spreading sequences are allowed, unless there is some sort of
  244. additional crypto layer in the system.  note that the fcc does not allow hams
  245. to pre-encrypt their transmissions, as is suggested below.
  246.  
  247. >> Spread spectrum was not developed as an encryption scheme.
  248. >
  249. >Taking a wider view (no pun intended), spread spectrum is just another
  250. >method of implementing the physical layer.  If you want security,
  251. >encrypt the digital data prior to sending it to to the DSSS 
  252. >"pseudo noise" "mixer".
  253.  
  254. ------------------------------------------------------------------------------
  255.  
  256. Miscellaneous issues
  257.  
  258. a comment on who is making ss systems (?)
  259.  
  260. >Maxim is now offering some of the 9 GHz process technology they bought 
  261. >from Tektronix.  They have a spread spectrum transmitter chip you might 
  262. >want to look at.  They also have technical information about spread 
  263. >spectrum to help you.
  264.  
  265. another comment on something relevant to making listening devices ?  i'm
  266. not sure what this poster intended!
  267.  
  268. >Look up companies QEI and CYLINK. Cylink is in Calf. Both about $5grand. One 
  269. >is audio only while Cylink is digital u to 500kbaud for real time video 
  270. >digital stuff. 1200 units can be on same channle AT ONCE?
  271.  
  272. one poster's thought on jamming and encryotion:
  273.  
  274. >Wasn't one of the main purposes of spread spectrum to make it
  275. >harder to jam a signal?  The encryption is just ancillary, and
  276. >not that good?  The encryption only becomes secure when you 
  277. >use a one time pad...right?a
  278.  
  279. and the response (i don't want this to become a thread on how easy it
  280. is to hide a ss system.  i'm guessing that it would be very difficult
  281. given the fcc's mandate (if one poster's statement is correct) that
  282. only a few (maybe as few as two) spreading sequences be allowed.)
  283.  
  284. >Spread spectrum was not developed as an encryption scheme.  The 
  285. >properties that makes it desirable are :
  286. >
  287. > Protection against jammers.  This is measured in the AJ (anti-
  288. >  jam) ratio.  Some simple math shows how much more jammer
  289. >  energy is needed to cause bit errors(digital communications)
  290. >
  291. > Low probability of intercept.  SS signals can be placed below the
  292. >  noise floor in many cases.  This means that covert operation
  293. >  can be conducted with some communications.
  294.  
  295.  
  296.  
  297. ---
  298. ========================================================================
  299. david r wolf - wolf@lanl.gov - 1+505-667-3813 - 1+505-662-9102 -- wb4vcq
  300. ========================================================================
  301.  
  302. ------------------------------
  303.  
  304. Date: Mon, 15 Aug 94 21:10:17 MST
  305. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!swrinde!cs.utexas.edu!asuvax!ennews!stat!david@network.ucsd.edu
  306. Subject: [Q] best software for KAM+ 
  307. To: ham-digital@ucsd.edu
  308.  
  309. khopper@kimbark.uchicago.edu (Kenneth C Hopper) writes:
  310.  
  311. > New KAM+ owner seeks good software suggestions.
  312. > OP only on HF.
  313.  
  314. I'm running Version 9.02 of KaGold for the KAM.  Been very happy with
  315. it.
  316.  
  317. david wb7tpy
  318.  
  319. ---
  320. Editor, HICNet Medical Newsletter
  321. Internet: david@stat.com                 FAX: +1 (602) 451-1165
  322. Bitnet  : ATW1H@ASUACAD
  323.  
  324. ------------------------------
  325.  
  326. Date: 16 Aug 1994 15:31:59 GMT
  327. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!howland.reston.ans.net!usenet.ins.cwru.edu!cleveland.Freenet.Edu!ei938@network.ucsd.edu
  328. Subject: AUTOEXEC.NOS for NOS with BAYCOM modem
  329. To: ham-digital@ucsd.edu
  330.  
  331. Packet Radio Gurus:
  332. Would an Elmer help me out of this NOS jam?
  333.  
  334. I need a copy of an AUTOEXEC.NOS file for a PA0GRI NOS configuration on my PC.
  335. I am using a BAYCOM modem (finally got that working... more details after I
  336. work out the bugs) and the AX.25 drivers for BAYCOM.  I had a working copy,
  337. but during configuration/testing, it got corrupted and now it is scrambled.
  338. My backup NOS.ZIP got scrambled too, so next time I am keeping the backup on
  339. the shelf rather than on the computer.
  340.  
  341. I was trying to set the entire system up on a 1.44MB floppy disk, but it somehow
  342. did not set up correctly.  I think the floppy may be on the fritz...
  343.  
  344. Can/would anyone help out and send me a copy of their AUTOEXEC.NOS for NOS with
  345. BAYCOM modem?  Thank you in advance.
  346.  
  347.  
  348. 73!
  349.  
  350. Andrew Lynch, N8VEM
  351. alynch@wpgate1.wpafb.af.mil
  352.  
  353. ------------------------------
  354.  
  355. Date: 16 Aug 1994 17:15:53 GMT
  356. From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!gatech!swrinde!elroy.jpl.nasa.gov!lll-winken.llnl.gov!earl.llnl.gov!user@network.ucsd.edu
  357. Subject: Does a FAQ exist for packet newbys?
  358. To: ham-digital@ucsd.edu
  359.  
  360. If so, where would I find it?
  361.  
  362. Thanks,
  363. Gary
  364.  
  365. ---------------------------------------------------------------------------
  366.    The ramblings expressed above do not reflect the opinions of LLNL.
  367.  
  368.    Gary Ross                                         Ross@NOVAX.LLNL.GOV
  369.    Lawrence Livermore National Laboratory            Rossman@eworld.com    
  370.  
  371.    NOVA Laser Operations                             Rossman@aol.com
  372.    P.O. Box 808, L-489                             
  373.    Livermore, CA 94551                             
  374.  
  375.  
  376.                              
  377.    
  378.   
  379.  
  380. ------------------------------
  381.  
  382. Date: 16 Aug 1994 10:31:55 -0700
  383. From: enews.sgi.com!wdl1!ltis.loral.com!not-for-mail@decwrl.dec.com
  384. Subject: Gateway within CA?
  385. To: ham-digital@ucsd.edu
  386.  
  387. Is there a gateway in CA that can be used for traffic between a CA
  388. packet address and a CA internet address?  Or is gate@wb7tpy.ampr.org
  389. the only one to be used?
  390.  
  391. Thanks for the help.
  392. -- 
  393.   
  394.   hlb@ltis.loral.com     
  395.  
  396. ------------------------------
  397.  
  398. Date: Fri, 12 Aug 94 13:38:31 BST
  399. From: pa.dec.com!csu.napier.ac.uk!ee17@decwrl.dec.com
  400. Subject: Jnos-Enet Solved TnX !
  401. To: ham-digital@ucsd.edu
  402.  
  403. Thanks for all the helpful replies to my problem re connecting an 
  404. ethernet packet driver to Jnos.
  405. All sorted out now and working Tickety-Boo   :-)
  406.  
  407. PS If your ethernet is not 'flat' remember to add this to your auto.nos:
  408.  
  409. route add default <devicename>  <router IP address>
  410.  
  411. otherwise you won't get off of the segment your on !!
  412.  
  413. regards and thanks again,
  414.  
  415. %% Alastair J. Downs          \__\_\_\    a.downs@csu.napier.ac.uk %%  
  416. %% E.E & Comp.Eng.Dept.        \ |\ \ \     phone +44 31 455 4389  %%  
  417. %% Napier University, Edinburgh  |  _       fax:  +44 31 455 7938  %% 
  418. %% Scotland, UK                  |_| |_   GM6NEI@GB7EDN.#77.GBR.EU %%
  419.  
  420. ------------------------------
  421.  
  422. Date: Mon, 15 Aug 1994 17:02:25 +0000
  423. From: ihnp4.ucsd.edu!ucsnews!sol.ctr.columbia.edu!howland.reston.ans.net!pipex!demon!myth.demon.co.uk!zeus@network.ucsd.edu
  424. Subject: JVFAX Interfaces?
  425. To: ham-digital@ucsd.edu
  426.  
  427.  I am currently running JVFAX 5.1 (anyone know a FTP site for a more recent 
  428. version?) with the simple comparator interface. Before I launch head on into 
  429. building the full AM/FM serial port version, are there any plans to use the 
  430. Sound Blaster ADC?, or are there any alternative circuits, since the ADC chip 
  431. is proving difficult to source. Cheers.
  432.  
  433. Mike.
  434.  
  435. -- 
  436.  
  437.  Michael S. Cowgill (Mike)        \_ My opinions!  MINEMINEALLMINEHAHAHAHA!
  438.  zeus@myth.demon.co.uk (That's me) \_       " Swirly thing alert! "
  439.  G1VOX@GB7WRG.GBR.EU 44.131.2.76    \_ "  ...Cracking toast Gromit!... "
  440.  
  441. ------------------------------
  442.  
  443. Date: Mon, 15 Aug 1994 17:45:46 +0000
  444. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!agate!doc.ic.ac.uk!uknet!pipex!demon!llondel.demon.co.uk!dave@network.ucsd.edu
  445. To: ham-digital@ucsd.edu
  446.  
  447. References <JAY.39.2E4A3859@medicine.dmed.iupui.edu>, <1994Aug12.154901.27305@ke4zv.atl.ga.us>, <32h270$12t@hpbab.mentorg.com>
  448. Subject : Re: Packet Node Info Wanted
  449.  
  450. There seems to be a load of rubbish in this thread! While DXing to a 
  451. distant BBS is usually not a good idea, on the basis that it should have 
  452. the same bulls as your local one, the network should be able to handle a 
  453. bit of interactive traffic between users who are several nodes apart. I 
  454. have in the past had useful chats with amateurs several hundred miles 
  455. away using the node system - when replies arrive in under a couple of 
  456. minutes it is no problem at all. 
  457.  
  458. Having said that, I can sympathise with those who maintain large chunks 
  459. of the network with no support - my local network is effectively run by 
  460. three people, with occasional help from a few others. There are probably 
  461. 600+ users in the coverage area.
  462.  
  463. Dave
  464. --
  465.  
  466. *****************************************************************************
  467. * G4WRW @ GB7WRW.#41.GBR.EU AX25     *                                      *
  468. * dave@llondel.demon.co.uk  Internet *  Stop the World! I want to get off!  *
  469. * g4wrw@g4wrw.ampr.org      Amprnet  *                                      *
  470. *****************************************************************************
  471.  
  472. ------------------------------
  473.  
  474. Date: Tue, 16 Aug 1994 13:01:58 GMT
  475. From: ihnp4.ucsd.edu!dog.ee.lbl.gov!overload.lbl.gov!agate!howland.reston.ans.net!gatech!wa4mei!ke4zv!gary@network.ucsd.edu
  476. To: ham-digital@ucsd.edu
  477.  
  478. References <326vf6$dir@eagle.natinst.com>, <1994Aug9.135536.9869@ke4zv.atl.ga.us>, <1994Aug15.170956.24013@arrl.org>mei
  479. Reply-To : gary@ke4zv.atl.ga.us (Gary Coffman)
  480. Subject : Re: local organizations that help people get acquainted with packet radio
  481.  
  482. In article <1994Aug15.170956.24013@arrl.org> zlau@arrl.org (Zack Lau (KH6CP)) writes:
  483. >An interesting path I've worked twice on all bands from 1.3 to 
  484. >10 GHz is Mt Equinox to Woburn, MA.  While Equinox is at 3800 ft, 
  485. >there is Grand Manadnock at 3165 ft. almost in the center of 
  486. >the path (54% of the way there).  On 2 meters, I need 10 watts 
  487. >and a 10 dBi antenna--with 2 watts to a 7 dBi antenna I need 
  488. >someone to relay!  But, this knife edge path is workable all the 
  489. >way through 10 GHz running QRP.  Path length is 179 km.
  490.  
  491. Fine, but could you guarantee a 60 db fade margin 7x24 52 weeks a year,
  492. and no heavy multipath? That's what you need for a reliable data link 
  493. at a resonable speed (1 Mb+).
  494.  
  495. Gary
  496. -- 
  497. Gary Coffman KE4ZV          |    You make it,     | gatech!wa4mei!ke4zv!gary
  498. Destructive Testing Systems |    we break it.     | uunet!rsiatl!ke4zv!gary
  499. 534 Shannon Way             |    Guaranteed!      | emory!kd4nc!ke4zv!gary 
  500. Lawrenceville, GA 30244     |                     | gary@ke4zv.atl.ga.us
  501.  
  502. ------------------------------
  503.  
  504. End of Ham-Digital Digest V94 #274
  505. ******************************
  506.